Well, Pacejka applied to a rigid cylinder (or doughnut) will be a lot better for the CPU than the default LFS deformable tires. Although I agree that basic friction will be much better.
And if you put dummy cars in real life, you will probably lock their tires. Also, moving tires will be harder in terms of physics and will require some modeling.
And if you put dummy cars in real life, you will probably lock their tires. Also, moving tires will be harder in terms of physics and will require some modeling.
Last edited by Ivo Georgiev, .
Oh, come on, it will need tire physics, also. That will be hard to process. Maybe a simpler tire model (let's say Pacejka) and a simpler suspension model for the dummy cars will solve the problem. Come on, we don't need accurate simulation of dummy cars. I think damage modeling won't be an issue, because it gets triggered only in collision, and in LFS, it gets easily synced online.
My suggestion is, using LFS deformation physics, to add deformable tire walls.
My suggestion is, using LFS deformation physics, to add deformable tire walls.
Last edited by Ivo Georgiev, .
How about keeping the current setup options, maybe adding more (let's say more maximum lock), and then adding the option for every server, to limit precisely the setup options, so every server admin can decide what option to limit in his server. For example, an racing server should limit the maximum lock. I read somewhere that intake restriction and so on can also be forced by the server. That should be possible for all setup options.
That will also bring the ability for racing servers to limit the setup only to driving style adjustments.
That will also bring the ability for racing servers to limit the setup only to driving style adjustments.
Well, how is this problem fixed in physics engines like ODE? Is collision checking simply running at a higher rate?
I supose there should be a simple 2d collision system getting updated much more frequently than the 3d collision one, and if the 2d collision system detects a collision between the car and the bareer, it calls the 3d collision system to sort out the stuff.
That solves the things in this way: when the 3d collision system is updated 200 times per second, the collision may be detected when the car is already on the barrier, as we know. However, the 2d collision system is much faster and won't slow down the game if it runs at much higher rate. It will detect when the car has touched the barrier (in a 2d way), and in this case it will update the 3d collision system one more time then the usual 200 times per second.
However, if the car is above the barrier, the 3d collision system will not detect collision at all so that's not an issue.
I supose there should be a simple 2d collision system getting updated much more frequently than the 3d collision one, and if the 2d collision system detects a collision between the car and the bareer, it calls the 3d collision system to sort out the stuff.
That solves the things in this way: when the 3d collision system is updated 200 times per second, the collision may be detected when the car is already on the barrier, as we know. However, the 2d collision system is much faster and won't slow down the game if it runs at much higher rate. It will detect when the car has touched the barrier (in a 2d way), and in this case it will update the 3d collision system one more time then the usual 200 times per second.
However, if the car is above the barrier, the 3d collision system will not detect collision at all so that's not an issue.
FGED GREDG RDFGDR GSFDG